\section{The \sicl{} source code}

\sicl{} is a system that is written entirely in \commonlisp{}.  We
decided to use the full language to implement the system so as to
avoid having to define and remember what subset of the language is
allowed for which modules.  Thus, the compiler, called Cleavir%
\footnote{Cleavir resides in the \sicl{} repository on GitHub.},
makes heavy use of generic functions and classes.  By using these two
types of objects, we can have a compiler that is adaptable to
different \commonlisp{} implementations.  It is currently used as the
main compiler of Clasp%
\footnote{https://github.com/clasp-developers},
and recently, a Cleavir-based compiler has
been written for CLISP%
\footnote{https://clisp.sourceforge.io/}.

In addition to using the full language for the implementation of
\sicl{}, we want the code to be as idiomatic as possible.  For
example, our definition of the class \texttt{t}, looks like this:

\begin{verbatim}
(defclass t ()
  ()
  (:metaclass built-in-class))
\end{verbatim}

\noindent
This definition clearly expresses the characteristics of the class
\texttt{t}.  It has no superclasses because no superclasses are
explicitly mentioned, and the metaclass \texttt{built-in-class} does
not provide any default superclasses like \texttt{standard-class}
and

\texttt{funcallable-standard-class} do.  While this definition of the
class \texttt{t} is clear, it is not operational as is.  The metaclass

 \texttt{built-in-class} is an indirect subclass of the class
\texttt{t}, so the class \texttt{t} must exist in order for the class
\texttt{built-in-class} to exist.

Our definitions of the classes \texttt{class} and
\texttt{standard-class} look like this:%
\footnote{In reality, there are intermediate classes between
  \texttt{class} and \texttt{standard-class} that are not shown here.}

\begin{verbatim}
(defclass class (specializer)
  ((%name :initform nil :initarg :name ...)
   ...
   (%direct-subclasses :initform '() ...)))
\end{verbatim}

\begin{verbatim}
(defclass standard-class (class)
  (...))
\end{verbatim}

\noindent
Again, these definitions are clear.  No metaclass option is given, so
the metaclass defaults to \texttt{standard-class}.  Like the defintion
of \texttt{t}, these definitions are not operational as is, because
the class \texttt{standard-class} must exist in order to be the
metaclass of itself.

In a \commonlisp{} implementation that must bootstrap \clos{} from a
subset of the language that does not include \clos{}, some other
mechanism must be used.  As an example of the consequences of the use
of such a subset, consider the following definitions from ECL%
\footnote{https://common-lisp.net/project/ecl/}:

\begin{verbatim}
(defparameter +class-slots+
  `(,@+specializer-slots+
    (name :initarg :name :initform nil ...)
    ...
    (direct-subclasses :initform nil ...)
    ...))
\end{verbatim}

\begin{verbatim}
(defparameter +standard-class-slots+
  (append +class-slots+
          '((optimize-slot-access)
            (forward))))
\end{verbatim}

\noindent
Here, two special variables are defined, each one containing the
specifications of the direct slots of a class.  These two definitions
express the exact same information as two \texttt{defclass} forms
defining the classes \texttt{class} and \texttt{standard-class},
respectively.  However, because the \texttt{defclass} form can not be
used at this stage of the bootstrapping procedure, a different mechanism
must be used.

In addition to using the \clos{} machinery for defining the classes
defined by the metaobject protocol, we use the same machinery for
defining system classes.  For example, our definition of the class
\texttt{symbol} looks like this:

\begin{verbatim}
(defclass symbol (t)
  ((%name :reader symbol-name)
   (%package :reader symbol-package))
  (:metaclass built-in-class))
\end{verbatim}

\noindent
Not only is this definition clear, it is also operational.  By using
the \clos{} machinery for definitions of system classes, we avoid
having to use an additional, special, mechanism for this purpose.

In contrast, consider this definition of the system class
\texttt{symbol} from SBCL:

\begin{verbatim}
(define-primitive-object
    (symbol :lowtag other-pointer-lowtag
            :widetag symbol-header-widetag
            :alloc-trans %make-symbol
            :type symbol)
  ...
  (name :ref-trans symbol-name :init :arg)
  (package :ref-trans symbol-package
           :set-trans %set-symbol-package
           :init :null)
  ...)
\end{verbatim}

\noindent
Again, a special mechanism must be used, since \clos{} is not
available when the type \texttt{symbol} must be defined.

The purpose of the \sicl{} bootstrapping procedure is to make these
idiomatic definitions operational in the host environment so as to
create a graph of objects isomorphic to that of the target system, and
then to create the target graph in an executable file.

By doing it this way, we simplify system maintenance.  The
bootstrapping procedure is able to work with the definitions of
classes, generic functions, and methods using the standard macros
\texttt{defclass}, \texttt{defgeneric}, and \texttt{defmethod}, even
though these definitions would not be operational in a system that
needs to build up functionality from a language subset that does not
include \clos{}.  The \sicl{} maintainer is thus free to alter
definitions of core system objects, relying on the bootstrapping
procedure to make those definitions operational and ultimately turning
them into an executable system.
